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Intersection and union types denote conjunctions and disjunctions of properties. Using bidirectional 
typechecking, intersection types are relatively straightforward, but union types present challenges. 
For union types, we can case-analyze a subterm of union type when it appears in evaluation position 
(replacing the subterm with a variable, and checking that term twice under appropriate assumptions). 
This technique preserves soundness in a call-by-value semantics. Sadly, there are so many choices 
of subterms that a direct implementation is not practical. But carefully transforming programs into 
let-normal form drastically reduces the number of choices. The key results are soundness and com- 
pleteness: a typing derivation (in the system with too many subterm choices) exists for a program if 
and only if a derivation exists for the let-normalized program. 



1 Introduction 

To check programs in advanced type systems, it can be useful to spht the traditional typing judgment e : A 
into two forms, e ff A read synthesizes type A" and e JJ- A read checks ag ainst type A", an d requiring 



that the user write annotations on redexes. This bidirectional typechecking (iPierce and Turne r 1998) is 
decidable for many interestin g features, including intersection and urdon type s without syntactic markers. 
Tridirectional typechecking / Punfield and P fenning^ 2004 : Dunfield 2007b ) is essentially bidirectional, 



but union types are eliminated with the aid of a tridirectional rule that uses an evaluation context S : 

r;Ai h e'^A r;A2,x:A h ^[x] 



r;Ai,A2 h S[e']^C 



directL 



In this rule, T is an ordinary variable context and Ai,A2 is the concatenation of linear contexts; linear 
variables x in As essentially stand for subterms (occurrences) in the subject. directL gives e' a (linear) 
name x, so that a left rule, which decomposes types in the context A, can eliminate union types appearing 
in A. Instead of a direct union elimination rule like VE, we use directL together with a left rule VL. 

The'trAVB r,x:A h JJ.C T ,y:B S[y\ ]!y C T; A,x:A h e -il C r;A,x:BheJ|C 

tt; [VEl VL 

rh^[e']J|C r;A,x:A VB h eJ|C 

While evaluation contexts are defined syntactically, this rule is not syntax-directed in the usual sense: 
many terms have more than one decomposition into some (f [e'] where the subterm e' can synthesize a 
type. Under a left-to-right (functions first, arguments second) call-by- value semantics, even / a' has three 
decompositions S = [],(f = []x, S = /[],soa straightforward implementation of a system with directL 
would require far too much backtracking. Compounded with backtracking due to intersection and union 
types (e.g., if / : (Ai — j> A2) A (Bi — > B2) we may have to try both / : Ai — ^ A2 and f :Bi —?- B2), such an 
implementation would be hopelessly impractical. 
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This paper reformulates tridirectional typechecking (summarized in Section m to work on terms in a 
particular let-normal form, in which steps of computation are sequenced and intermediate computations 
are named. The let-normal transformation (Section |3]l drastically constrains the decomposition by se- 
quencing terms, forcing typechecking to proceed left to right (with an interesting exception). The results 
stated in Section|4]guarantee that the let-normal version of a program e is well typed under the let-normal 
version of the type system if and only if e is well typed under the tridirectional system. 

The let-normal transformation itself is not complicated, though the motivation for my particular 
formulation is somewhat involved. The details of the transformation may be of interest to designers of 
advanced type systems, whether their need for a sequential form arises from typechecking itself (as in 
this case) or from issues related to compilation. 

Unfortunately, the proofs (especially the proof of completeness) are very involved; I couldn't even fit 
all the statements of lemmas in this paper, much less sketch their proofs. I hope only to convey a shadow 
of the argument's structure. 

This paper distills part of my dissertation (|Dunfieldl l2007bL chapter 5). To simplify presentation, 
I omit tuples, datasort refinements, indexed types (along with universal and existential quantification, 
guarded types, and asserting types), and a greatest type T. 



2 Tridirectional Typechecking 



We have functions, products, intersections, unions, and an empty type _L. We'll use a unit type and other 
base types like int in examples. In the terms e, we have variables x (which are values) bound by Xx.e, 
variables u (not values) bound by fix u. e, and call-by-value application e\ e2- Note the lack of syntactic 
markers for intersections or unions. As usual, (^[e'] is the evaluation context S" with its hole replaced by 
e' . To replace a; with ei, we write [e\/x]e2'- "e\ forjcin 62". 



Types A,B,C,D 
Terms e 
Values V 
Evaluation contexts £' 



B I A A B I A V S I _L 
u I Xx.e \e\e2 \ fix u. e 
Xx.e 



Small-step reduction rules 

S{{Xx.e)v\ ^ (^[[v/x]e] 
(^[fixM.e] 1-^ [[(fix M. e) / m] e] 



We'll start by looking at t he "left tridirectional" (in this paper , called just "tridi rectional") system. 
This system was presented in bunfield and PfenningI too4 ) and IPunfieldl (l2007bL chapter 4); space 
allows only a cursory description. 

The subtyping judgment (Figure [T]) isA<B. Transitivity is admissible. A does not distribute across 

for reasons explained by Davies and PfenningI ([2OOO). 

Figure [2] gives the typing rules. The judgment r;A h e A is read "g synthesizes type A", and 
F; A h e J| A is read "e checks against A". When synthesizing, A is output; when checking, A is input. 



Contexts F 
Linear contexts A 



F,;c:A 
A,x:A 



Contexts F have regular variable declarations. Linear contexts A ::= • | A,x:A have linear variables. 
If F; A h e . . . is derivable, then "A Ih e ok", read "e OK under A": each x declared in A appears exactly 
once in e, and e contains no other linear variables. Rules that decompose the subject, such as — )•£ 
decomposing ei e2 into ei and ^2, likewise d ecompose A. 



Most rules follow a formula devised in iDunfield and PfenningI (|2004l ): introduction rules, such as 
^I, check; elimination rules, such as — >£, synthesize. Introduction forms like Xx.e thus construct 
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synthesizing terms, while elimination forms like ei e2 are checked terms. Some rules fall outside this 
classification. The assumption rules var, var and fixvar synthesize (an assumption x:A can be read JcffA). 
The subsumption rule sub allows a term that synthesizes A to check against a type B, provided A is 
a subtype of B. The rule ctx-anno permits contextual typing annotations; for example, in (succ x : 
(x:odd h even,x:even h odd)), the annotated term succ x is checked against even if x:odd € F, and 
against odd if x:even G Y. The premis e (Fn h A) < (F h A) i s deriv able if the assumptions in F support 
the assumptions in Fq. For details, see Dunfield and Pfenning! (120041) . 

Finally, we have left rules ALi, AL2, VL, _LL which act on Unear assumptions x:A where A is 
of intersection, union, or empty type. These act as elimination rules — for V and ±, they are the only 
elimination rules. ALi and AL2 are not useful alone (the ordinary eliminations AEi and AE2 would do) 
but are needed to expose a nested V for VL, or a _L for _LL. 

The backtracking required to choose between AEi and AE2, or between Vli and VI2, or between the 
related subtyping rules, as well as th e need to check a single term more than once (Al, VL) suggests that 
typechecking is exponential. In fact. iReynoldsl (1 1 996l pp. 67-68) proved that for a closely related system, 
typechecking is PSPACE-hard. We can't make typechecking polynomial, but "untangling" directL will 
remove one additional source of complexity. 



A<B 



Bi <A 



A2<B2 



Ai^A2<Bi^B2 

Ai<B 

■_LL< 



Ai<B 
A1AA2 <5' 

A2 <5 



■ALi< 



_L <A 



-VL< 



A2<B 
A1AA2 <5 

A<Bi 



AL2< 



A<B 



A<B2 



AiVA2<5 ~ A<5iV52 

Figure 1: Subtyping 



VRi< 



A <5iA52 
A<52 



AR< 



A <5iV52 



-VR2< 



r(jt:)=A r,x:A;- ^ ei^B r;Ai h ej ^A^B r;A2he2-llA 

var var >l 



r;-\-xiiA r;x:AhxfrA F; • h Ax.e ^ A^B r;Ai,A2 h eie2 ffB 

F;Ah£'frA A<B , F(m)=A ^. F,m:A; • h e J| A ^. 

sub fixvar fix 

F;AheJ|B F-hMfrA F; • h fix m. e A 

r\-eok A,x:_Llheok (Fq h A) < (F h A) F;AheJ|A 

F;A,x:±h.^C F; A h (e : . . . , (Fo h A), . . . ) ^ A 

r;A,x:A h eJLC r;AheltAAB 

■ALi _ . , ., _ . , ,, : AEi 



r;A,x:AAB h eJ|C F;AhvJJ.A F;AhvJJ-B r;AhefrA 

r;A,x:BheJLC F;AhvJ|AAS r;Ahel*rAAB 

AL2 ^ . , ' „ AE2 



r;A,x:AAB h e|LC r;AI-efrB 

F;A,x:AheJLC F; A,x:B h e JJ. C F;AI-eJLA F;AheJl.B 

— — VL VI, VI2 

F;A,x:A VB h eJ|C F;Ah£'J|AVB F;AheJ|AVB 

F;Ai h e'i[A F;A2,x:A h (f[x] ^. 

F; A 1 , A2 h ^[e'] -IJ- C where e' is not a linear variable 

Figure 2: The left tridirectional system 
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2.1 Tridirectional typechecking and evaluation contexts 

Rule directL's use of an evaluation context might give the impression that typechecking simply proceeds 
in the order in which terms are actually evaluated. However, this is not the case. The subject of directL 
is (^le'] where e' synthesizes a type, so certainly e' must be in an evaluation position, but there may be 
several such positions. Even a term as simple as / {x y) has 5 subterms in evaluation position, each 
corresponding to a different evaluation context : 

<^=[]{xy) and e' = f; ^ = f {x []) and e' =y; = f [] and e' = {xy); 

S = f{[]y) and e' = x; <§=[] and e' = f {xy). 

In fact, we may need to repeatedly apply directL to the same subject term with different choices of S\ 
For example, we might use S =[] {xy)io name an / of union type, introducing f:A VB into the context; 
then, case-analyze A\JB with VE; finally, choose = f ([] y) to name x (also of union type). Thus we 
are faced not with a choice over decompositions, but over many sequences of decompositions. 

Typechecking cannot go strictly left to right. Given an ML-like int option type, containing None 
and some integer Some(?i), assume None : none and Some(?i) : some. Then, if map / (Some(?i)) returns 
Some(/ n) and map / None is none, then map : (int — > int) — > ((some — some) A (none — none)). 
Similarly, a function filtering out negative integers could have type filter : int — > (some V none). 

Consider the term (map /) (filter n). The term (map /) synthesizes (some some)A(none — )• 
none). This is an intersection type — we'll abbreviate it as (s^s)A(n— )-n) — and the intersection must be 
eliminated so that rule — >E can be applied to (map /) (filter x). However, we cannot commit to one part 
of the intersection yet, because we must first case-analyze the union type of the subterm (filter x). We 
need to "jump over" (map /) to type (filter x), so apply directL with evaluation context = [] (filters), 
giving (map /) the name x; second, apply directL with context (f = x [], synthesizing some V none for 
(filter x). Rule VL splits on y:someVnone; in its left subderivation i^some. we have y:some, so AEi on 
X -(I (some — )■ some) A (none none) gives x ft some — )• some, while its right subderivation ^none has 
y:none, so AE2 gives x f]- none none. Writing A for x:((s— )-s)A(n^n)), the derivation is 

■^some ^none ^ 



A h filter ;t lj some V none A,y:(someVnone) h x y JJ. C ^. 
h map f ft (s-^s) A(n^n) A h x (filter x) J| C 

h {mapf) (filter x)^C ""^^^^ 

where C is some V none, and the derivations ^some and ^none are 

... I- X ft (some^some) A(none— J-none) ... h x ff (some^some) A(none— J-none) 

1 - A -^Ei 1 _ . AE2 

... r X ft some — some ^j^^ . . . h x ff none none 

A,y:some h X y J|C A,y:none h x y JJ-C 

On a purely theoretical level, the tridirectional system is acceptable, but the nondeterminism is exces- 
sive. Xi approached (very nearly) the same problem by transforming the program so the term of V 
type appears before the term of A type. (Actually, Xi had index-level quantifi ers £ and H instead 



of V and A, but these are analogous.) A standard let-normal translation \e\ (IXil 11998 . p. 86), where 
1^1^21 = letxi = jei I in Ietx2 = 1^2! inxiX2 suffices for the examples above. (In Xi's system, existential 
variables are unpacked where a term of existential type is let-bound: an existential variable b' is un- 
packed at the binding of X2, which appears before the application X1X2 at which the universal variable a 
must be instantiated.) Unfortunately, the translation interacts unpleasantly with bidirectionality: terms 
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such as map (Xx.e), in which {Xx.e) must be checked, no longer typecheck because the A becomes the 
right hand side of a let, in letxi = mapin \etX2 = Xx.e'\nxiX2 and let-bound expressions must synthesize a 
type, but Xx. e does not. Typechecking becomes incomplete in the sense that some programs that were 
well typed are not well typed after translation. 



Xi ameliorated this incompleteness by treating e\V2 as a special case (|Xilll998l . p. 139): \e1V2 



let;t;i = |ei| \nxiV2- Now V2 (which is Xx.e in the above example) is in a checking position. This is 
adequate for non-synthesizing values, but terms such as map (case z of . . .), where a non-synthesizing 
non- value is in checking position, remain untypable. It is not clear why Xi did not also have special cases 
for case and other non-synthesizing non-values, e.g. \ei {case e ms)\ = \etxi = \ei\\nxi\case e of ms\. 
Xi's translation is also incomplete for terms like / (casex ofms). Suppose x synthesizes a union that 
must be analyzed to select the appropriate part of an intersection in the type of /. Since x's scope — and 
thus the scope of its union — is entirely within the let created for the case, typechecking fails. 

|/(casex of ms)| = let/i =/in letX() = |case x of mi'| in/i xq 

= let/i =/in letX() = (letxi =xin case xi of \ms[j in/i xq 

It could be argued that the cases in which Xi's translation fails are rare in practice. However, that 
may only increase confusion when such a case is encountered. I follow Xi's general approach of sequen- 
tializing the program before typechecking, but no programs are lost in my translation. 

Do we need all the freedom that directL provides? No. At the very least, if we do not need to 
name a subterm, naming it anyway does no harm. But naming all the subterms only slightly reduces the 
nondeterminism. Clearly, a strategy of in-order traversal is sound (we can choose to apply directL from 
left to right if we hke). It is tempting to think it is complete. In fact, it holds for many programs, but 
fails for a certain class of annotated terms. We will explain why as we present the general mechanism 
for enforcing a strategy of left-to-right traversal except for certain annotated terms. 



3 Let-Normal Typechecking 



We'll briefly mention previous work on let-normal form, then explain the ideas behind the variant here, 
including why we need a principal synthesis of values property. Because the most universal form of 

principality does not hold for a few terms, we introduce slack binding s. 

Traditional let-normal or A-normal transformations (.Moggilll988 : Flanagan et al. Ill993h (1) explicitly 
sequence the compu tation , and (2) name the result of each intermediate computation. (Continuation- 
passing style (CPS) (lReynoldslll993h also (3) introduces named continuations. Thus let-normal form is 
also known as two-thirds CPS.) Many compilers fo r functional languag e s use some kind of let-normal 



Reppvl (l200lh . IChlipala et al. 



form to facilitate optimization s; see , for instance, iTarditi et all (II 99' 
(|2005h . and Peyton Jones et al. (|2006h . 

Our let-normal form will sequentialize the computation, but it does not only name intermediate 
computations, but values as well. In our let-normal type system, directL is replaced by a rule let that can 
only be applied to let; see Figure[3] is a special evaluation context, discussed below. 

This let is a syntactic marker with no computational character. In contrast to let-normal translations 
for compilation purposes, there is no evaluation step (reduction) corresponding to a let. I won't even 
give a dynamic semantics for terms with lets. It would be easy; it's simply not useful here. If we insist 
on knowing what a let-normal term e means, we can use a standard call-by-value operational semantics 
over the term's reverse translation. 

Instead of making explicit the order of computation, our let-normal form makes explicit the order of 
typechecking — or rather, the order in which directL names subterms in evaluation position. Thus, to be 
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r-Aihe'ilA r;A2,x:A h ^[x] ^C, 

let 

r;Ai,A2 h letx=e'in^[x] J|C 

r;A,~x = v h ^[x] , r;AihvltA T; A2,x:A h e J). C 

Iet~ 

r;A h let~x = vin^[x] J|C r;Ai,A2,~x = v h eJJ-C 

. . .plus all rules in Figure^ except directL 

Figure 3: The let-normal type system for terms containing let x bindings 



complete with respect to the tridirectional system, the transformation must create a let for every subterm 
in synthesizing form: if an (untranslated) program contains a subterm e' in synthesizing form, it might 
be possible to name e' with directL, so the let-normal translation must bind e' . Otherwise, a chance to 
apply VL is lost. Even variables x must be named, since they synthesize a type and so can be named in 
directL. This models an "aggressive" strategy of applying directL. On the other hand, checked terms 
like Xx. e can't synthesize, so we won't name them. 

Another consequence of the let-normal form following typing, not evaluation, is that letx = vi in V2 is 
considered a value — after all, the original term [vi /x] V2 was a value, and we transformed a value into a 
non- value we could not apply value-restricted typing rules such as AI, leading to incompleteness. 

We define the translation by a judgment e ^ L + e' , read "e translates to a sequence of let-bindings 
L with body e'". For example, the translation of f [xy), which names every synthesizing subterm, is 

letf=/in letx=A'in lety=y in letz=x y in leta=f zina 

This is expressed by the judgment f {xy) ^ f=/,x=A;,y=y,z=x y,a = f z + a. Figure |4]has the defi- 
nition. Note that L + e' is not a term; + is punctuation. We write L in e' as shorthand: read e ^ L + e' 
as "e <^ L in e'". The divergent notations come from the multiple decompositions of a term into a 
pair of bindings and a "body". For example, letxi =e\ in letX2 = e2 in ^3 can be written three ways: (1) 
■ in letxi =^1 in letX2 = e2 in^3> (2) {x\_=e\) in letX2 = e2 ine3, or (3) {x\=e\,X2=e2) in ^3. The last de- 
composition is maximal: it has the maximum number of bindings (and the smallest 'body'), which is the 
case when the body isn't a let. \f e ^ L + e' then L in is maximal. 

Again, to model a complete strategy of directL-application, in e L + e' we need L to bind all the 
synthesizing subterms that could be in evaluation position (after applying directL zero or more times). 

We syntactically partition terms into pre- and a«f/-values. A pre-value e is a value, such as x, or a 
term that can "become" a value via directL, such as x 3^ which "becomes" the value z in the derivation. 
(The hacek ^ above the e is shaped like a ' v' for 'value' .) An anti-value e, such as Wxu.e (or case e of ms) 
is not a value and cannot become a value. 

directL can replace any synthesizing subterm with a linear variable, so the pre-values must include 
both the values and the synthesizing forms. This leads to the following grammar for pre-values, with 
values X, x, and Xx.e and synthesizing forms {e : As), e\e2, u. (In the full system, the pre values also 
include checking forms that can become values if all their subterms can, such as (^1,^2).) 

Pre-values e ::= x | x | :As) \ Xx.e \ e\e2 \ u 
Anti-values e ::= fixw.e 

The distinction matters for terms with sequences of immediate subterms such that at least two subterms 
in the sequence may be in evaluation position. Only application eie2 has this property (and in the full 
system, pairs (^1,^2))- Xx.e and fix u.e have no subterms in evaluation position at all. 
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g <— ). L + e' rc^d "e translates to bindings L with result e'" 

e ^ L + e' 



x^{x=x)+x Xx.e ^ ■ + Xx.{Lm e') 

e ■-^ L + e' 



u^{x = u)+x fix M. e ^ • + fix M. (L in e') 





+ e[ L2 + e'2 


ei^Li+e'^ e2^L2 + e'2 


e\e2 ^ 


Li,x = e'i{L2 in e'2) +x 


eie2 ^ Li,L2,x = e\e'2 + x 


e ^ L + e' 


e not a value 


V ^ L + e' 


{e -.As) ^ L,x 


= (e':Ai')+x (v:Ai') 


^ L,^x={e' : As) +x x^- + x 



Figure 4: The let-normal transformation 



A telling example is (fix u. e) (ft) x) where ftj : . . . ^ ±. In the tridirectional system, this term has no 
synthesizing subterms in evaluation position. In particular, ftj a; is not in evaluation position, so however 
we translate the term, we must not bind (O x outside the outer application; if we did, we would add z:_L 
to the context and could apply rule ±L to declare the outer application well typed while ignoring e\ If 
e is ill-typed, this is actually unsound. On the other hand, in the term {f g) {(0 x) the left tridirectional 
system can bind co x before checking the pair, by applying directL with S' = [] {co x) (synthesizing a 
type for / g, ensuring soundness) to yield a subject x {(O x) in which ftj ;c is in evaluation position. 

The difference is that Wxu.e is an anti- value, while / g is a pre- value. Therefore, given an application 
e\ e2, if e 1 is some anti-value ei , the translation places the bindings for subterms of e2 (e.g. z = cox above) 
inside the argument part. On the other hand, if ei is a pre- value e\, the translation puts the bindings for 
subterms of e2 outside the application. See the shaded rules in Figured 

Elongated evaluation contexts £2, unlike ordinary evaluation contexts (f , can skip over pre-values. 

is a sort of transitive closure of <§ : if, by repeatedly replacing pre-values in evaluation position with 
values, some subterm is then in evaluation position, that subterm is in elongated evaluation position. In 
a sequence of directL-applications, subterms in evaluation position are replaced with linear variables, 
which are values. For example, z is not in evaluation position in {x y) z, but applying directL with 

= [] z yields a subderivation with subject x z, in which z is in evaluation position. A =S is thus a 
path that can skip pre-values: if every intervening subterm is a pre- value (equivalently, if there is no 
intervening anti-value), the hole is in elongated evaluation position. The grammar for let-normal terms 
ensures that the body ^2 of letx=ei in ^2 must have the form cS[x]. 



Elongated ^ 
evaluation contexts 

Terms e 

Values V 
Eval. contexts 

Sequences of bindings L 



[]\^e\e^\ (^-.As) 

letx = <^ine | letx = ein^ | let~x = <^ine | let~x=vin=S 
... I letx = ei in =2[x] | let ~x = vi in =S[x] 
X I Xx.e I X I letx = vi inv2 | let~x = vi inv2 
... I \etx = S'\ne \ \etx = v\nS' \ let~x = (f ine | let~x = vin( 
• I L,{x = e) I L,(~x=v) 
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3.1 Principal synthesis of values 

A key step in completeness i s the moveme nt of let-bindings outward. To prove this preserves typing, 
we show that principal types ( Hindley 1969h exist in certain cases. Consider the judgment x : (Ai^B) A 



{A2^B),y : Ai V A2; • \- x y ij. B. To derive this in the left tridirectional system, we need directL with 
= x[]to name j as a new linear variable y:A[ V A2. Then we use VL; we must now derive 

x:{Ai^B)A{A2-^B),...;y:Ai\-xyij.B and x : (A^-^B) A {A2-^B), . . .-yAj ^ xy i}, B 

Here, the scope of y is x y, and we synthesize a type for x twice, once in each branch: 

^ xiiAi^B ': ...-hx^Aa^B ': ^ 

-^E ■ : >E 



■ .■;y:Ai hxyi^B . . . ;y:A2 h x y # g 

...,3;:Ai VAa;- hj^Ai VA2 ...;y : Aj VA2 h xy 

; ^ ^ directL 

x: (Ai^B) A {A2^B),y:Ai VA2;- h xyJ^B 

However, when checking the translated term letx=xinlety=jinletz=xyinz against B, we need to first 
name x as x, then y as y, then use VL to decompose the union y:Ai V A2 with subject let z=x y in z. 

h xfr (Ai^B) A (A2^B) ...;x:(Ai^B) A (A2^B) h lety=3; in letz=x yinz 



X : (Ai— ^B) A (A2— 7'B),y : Ai V A2; • H letx=xin lety=jin letz = x y inz JJ-B 



let 



But we only get one chance (highlighted above) to synthesize a type for x, so we must take care when 
using let to name x; if we choose to synthesize x ft Ai— J-B in let, we can't derive 

x:Ai— >B,y:A2 h (letz=x y inz) JJ-B 

but if we choose to synthesize x f|- A2— )-B we can't get 

x:A2^'B,y:Ai h (letz = x y inz) JJ.B 

The only choice that works is r(x), which is (Ai^B) A (A2— i>B), since given xf^ (Ai^B) A (A2— ^B) 
we can synthesize x f Ai B and x ft A2 ^ B using AEi and AE2, respectively. 

In the above situation, = x is a variable, so there is a best type C — namely r(x) — such that if x ft Ci 
and X ft C2 then x ft C, from which follows (by rules AEi,2 in the example above) x ft Ci and x ft C2. We'll 
say that x has the property of principal synthesis. Which terms have this property? Variables do: the best 
type for some x is r(x). On the other hand, it does not hold for many non- values: / x ft Ai and / x ft A2 
do not imply / x ft Ai A A2, since the intersection introduction rule AI is (1) restricted to values and (2) in 
the checking direction. Fortunately, we don't need it for non-values: Consider {ei ^2) y- Since {ei ^2) is 
not a value, y is not in evaluation position in (^1^2) y, so even in the tridirectional system, to name y we 
must first name (^1^2)- Here, the let-normal system is no more restrictive. Moreover, some values, such 
as pairs, are checking forms and never synthesize, so they do not have the principal synthesis property. 
But neither system binds values in checking form to linear variables. 

Now, do all values in synthesizing form have the principal synthesis property? The only values in 
synthesizing form are ordinary variables x, linear variables x, and annotated values (v : As). For x or x 
the principal type is simply r(x) or A(x). Unfortunately, principal types do not always exist for terms of 
the form (v : As). For example, ((Ax.x) : (h unit — > unit), (h bool — > bool)) can synthesize unit unit, 
and it can synthesize bool bool, but it can't synthesize their intersection, so it has no principal type. 
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3.2 Slack bindings 

Rather than restrict the form of annotations, we use a different kind of binding for (v : As) — a slack 
binding ~x = v where v's type is synthesized not at its binding site, but at any point up to its use (rules 
~var and let~ in Figure O. Wherever x is in scope, we can try rule ~var to synthesize a type A for v 
and replace ~x = v with an ordinary linear variable typing x:A. For example, [{Xx.e) : (h int— >int)) y 
is translated to let ~x= ((Ax. e') : (h int^int)) in lety=)'inxy. Now, we have several chances to use 
~var to synthesize the type of x: just before checking lety=j inx y, or when checking x y. This is 
just like choosing when to apply directL in the tridirectional system. If all our bindings were slack we 
would have put ourselves in motion to no purpose, but we' ll use slack bind ings for (v : As) only. My 



experiments suggest that slack bindings are rare in practice (|Dunfieldl l2007bl . p. 187), and are certainly 



less problematic than the backtracking from intersections and unions themselves (AEi 2, etc.). 



4 Results 

The two major results are soundness: if the let-normal translation of a program is well typed in the 
let-normal type system, the original program is well typed in the left tridirectional system — and com- 
pleteness: if a program is well typed in the left tridirectional type s ystem, its translation is well t yped 



in the let-normal type system. Once these are shown, it follows from lDunfield and Pfenning (12004) that 
the let-normal system is sound and complete with respect to a system ( Dunfield and PfenningI 2003 ) for 
which preservation and progress hold under a call-by- value semantics. 

At its heart, the let-normal system merely enforces a particular pattern of linear variable introductions 
(via let, inste ad of directL). So it is no surprise that soundness holds. The proof is syntactic, but not too 



involved; see lDunfieldl (l2007bl . pp. 132-134) 



Corollary (Let-Normal Soundness). 

Ife^L + e' and •; • h L in J| C (let-normal system) then ■;■ \- e i^-C (tridirectional system). 

However, completeness — that the let-normal system is not strictly weaker than the t r idirecti onal 
system — is involved. What follows is the roughest sketch of the proof found in bunfield ( 2007bL pp. 



135-165). We want to show that given a well-typed term e, the let-normal translation L in e' where 
e ^ L-\-e' is well-typed. To be precise, given a derivation deriving r;A h e J| C in the left tridi- 
rectional system, we must construct a derivation F; A h L in JJ. C in the let-normal system, where 
e ^ L-\-e'. My attempts to prove this by straightforward induction on the derivation failed: thanks to 
directL, the relationship between e and ^ is complex. Nor is L + e' compositional in e: for a given 
subterm of e there may not be a corresponding subterm of L + e', because translation can insert bindings 
inside the translated subterm. 

Instead, the completeness proof proceeds as follows: 

1. Mark e with lets wherever directL is used in However, if Al or another subject-duplicating 
rule is used, the subderivations need not apply directL in the same way, resulting in distinct terms 
to which Al cannot be applied. So we use step 2 inductively to obtain typing derivations for the 
canonical version of the subterm (the L-\-e' from e L + e'), to which Al can be applied. 

This step centres on a lemma which produces a term with a let-system typing derivation. This term 
might not be canonical. For example, if the original tridirectional derivation for Xx.x didn't use 
directL at all, no let bindings are created, unlike the canonical let-normal term Ax. Ietx=xinx. 
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2. Transform the marked term into the canonical L + e' in small steps, adding or moving one let at 
a time. Each small step preserves typing. We'll define a syntactic measure /i that quantifies how 
different a term is from L + e'; each let-manipulating step reduces the measure, bringing the term 
closer to L + e'. When the measure is all zeroes, the term is L + e'. 

The measure of e' is 

pi{e') = (unbound^(e'), brittle(e'), prickly(e'), transposed(/)) 

where: 

• unbound^(e') is the number of subterms of e' in synthesizing form (that is, variables x and u, 
annotated terms {e : As), and applications eiej) that are not let-bound. The translation ^ has 
let-bindings for all such terms, so an e' that does not bind such terms is quite far from being in 
canonical let-normal form. 

• brittle(e') is the number of let-bindings in e' of the form let x = (vi : As) in ^2. To correspond to the 
translation ^ , we need to change such let-bindings to slack bindings let ~x = (vi : As) \ne2- These 
terms are "brittle" because they need to be slackened. 

• prickly(e') is the number of let-bindings in e' that are not properly collected together at a root. A 
root is somewhere that the canonical translation may place a sequence of let-bindings. In the 
proof, we start by reducing the number of unbound synthesizing forms by inserting lets nearby, but 
some of these are too deep inside the term. For example, given a term c y, we first put a binding 
around the y, giving c(lety=y iny). (To simplify the example, c is some constant or primitive 
operation that is never let-bound.) Then we bind the application, giving leta=c (lety=y iny) in a. 
But the canonical translation would be lety=3' in leta = c y ina. Thus, a prickly binding needs to be 
lifted outward until it is in some sequence of let-bindings at the outside of the body of a A or fix, 
or at the outside of the entire term e'. 

• transposed(e') is the number of transposed variable pairs in e'. If there are no prickly bindings, 
there may still be bindings that are out of order. For a term x y, the original derivation might have 
used directL first on y (with (f = []) then on x (with = [] y). In this case. Step 1 above would 
produce lety=y in letx=;cinx y. Supposing this application is the body of some A, these bindings 
are not prickly, but don't correspond to what ^ would produce. Variables (and their bindings) are 
transposed if they are not used in the same order they were bound. Thus, x and y are transposed 
in \ety=y in letx=xin x y, because y is bound before x but x appears to the left of y in the body of 
the let. 

We interpret the quadruples lexicographically. Likewise, the proof of completeness relies on type 
preservation lemmas for each part of the quadruple: adding a let-binding preserves typing, changing a 
regular let-binding to a slack let-binding preserves typing, lifting a let-binding to a root preserves typing, 
and reordering the bindings of transposed variables preserves typing. 

Theorem (Let-Normal Completeness). 

If ■;■ \- e il-C (tridirectional system) and e ^ L + e* ttien ■;■ \- L\n e* i}-C (let-normal system). 

5 Related Work 



The effects of transformation to continua tion passing style on the pr ecision of program analyses such as 
0-CFA have been studied for some time dSabry and Felleisenlll994) . The effect depends on the specific 
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details of the CPS transform and the analysis done ( Damian and Danvy 2001 : Palsberg and Wandll2003 ). 
The "analysis" in this work is the process of bidirectional checking/synthesis. My soundness and com- 
pleteness results show that my let-normal transformation does not affect the analysis. It is not clear if 
this means anything for more traditional let-normal transformations and compiler analyses. 



6 Conclusion 



Transforming programs into a let-normal form removes a major impediment to implementing tridirec- 
tional typechecking. Th e system is sound and compl ete with respect to a type a ssignm ent system for 
intersections and unions ( Dunfield and Pfenning 2003 ). in contrast to systems (|xi 1998 ) in which com- 
pletene ss is lost. The tri directional rule can be turned into something practical. A chain of soundness 
results (IDunfieldl l2007bL p. 165) guarantees that if we run a program e whose let-normal translation 
typechecks in the system in this paper, it will not go wrong. 

Despite "untangling" directL, typechecking is still very time-consuming in the worst cases, thanks 
to checking terms several tim es in Al and bac ktracking in AEi 2, etc. As implementing (an extended 
version of) this system shows (IDunfieldlbOOTah . bad cases do occur in practice! 

Parametric polymorphism is absent, but I have extended the tridirectional system and the let-normal 
implementation (Dunfield 2009), and the soundness and completeness results should still hold. 

The major flaw of this work is its completeness proof, which uses purely syntactic methods, is com- 
plicated, and has not been mechanized. Ideally, it would be mechanized and/or proved more simply. 
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